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Commissioner for Patents 
P.O. Box 1450 

Alexandria, VA 22313-1450 
Sir: 

This is an appeal pursuant to 35 U.S.C. § 134 from the Examiner's decision rejecting 
claims 1, 7, 12-18 and 23-28 as set forth in the final Office Action of June 16, 2008 and 
Advisory Action of October 7, 2008. 
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I. Real Party in Interest 

The real party in interest in this application and the appeal is Samsung Electronics Co., 
Ltd. by an assignment recorded February 20, 2004 on Reel 015010, Frame 0692. 

II. Related Appeals and Interferences 

There are no other related patents or applications related to this invention on appeal or 
that are involved in an interference proceeding. 

III. Status of Claims 

Claims 1, 7, 12-18 and 23-28 are pending and are the subject of this appeal. Claims 2-6, 
8-11 and 19-22 are canceled. Claims 1, 7, 12-18 and 23-28 stand finally rejected and are 
reproduced in the Claims Appendix (Section VIII). 

IV. Status of Amendments 

Amendments to the claims were filed on February 15, 2008 and were entered in the final 
Office Action mailed June 16, 2008. 

V. Summary of the Claimed Subject Matter 

The present invention is directed to a method and apparatus for performing Traffic Flow 
Template (TFT) filtering operations according to IP versions in a mobile communication system. 
In a conventional mobile communication system, as the number of subscribers increases, 128-bit 
IPv6 addresses are increasingly chosen over 32-bit IPv4 addresses as the IP addresses assigned to 
the subscribers, since the 128-bit IPv6 version can accommodate exponentially more IP 
addresses than the 32-bit IPv4 version. On the other hand, because bit-computations associated 
with IP addresses are needed during TFT filtering operations, bit computations associated with 
128-bit IPv6 addresses cause a significant load on TFT filtering operations compared with bit 
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computations associated with 32-bit IPv4 addresses, and thus degrade the performance of TFT 
filtering operations, which ultimately adversely affect the entire mobile communication system. 
See pages 24-25 of the specification. 

The present invention is at least designed to reduce computation-load resulting from bit 
computations associated with IP addresses during TFT filtering operations particularly involving 
a second IP version address (e.g. an IPv6 addresses) that contains a first IP version address (e.g. 
an IPv4 address). In achieving the reduction in computation load, the disclosed method and 
apparatus comprises steps or functional modules that are aimed to turn the otherwise more load- 
intensive bit computations associated with the second IP version address into the less load- 
intensive bit computations associated with the first IP version address. 

Independent claim 1 recites a method (exemplified by page 39, line 1 1 - page 40, line 7; 
page 43, line 9 - page 45, line 7; FIG. 5; FIGS. 19A-19B) for performing TFT filtering 
according to Internet Protocol (IP) versions in a mobile communication system, the method 
comprising the steps of: 

extracting a first IP version address from a source second IP version address (exemplified 
by page 39, lines 12 - 15; FIG. 11), wherein the second IP version address contains the first IP 
version address (exemplified by page 39, lines 17-20; FIG. 1 1); and 

generating TFT information using the first IP version address (exemplified by page 39, 
line 17 - page 40, line 7; FIG. 6), wherein the TFT information contains an indication that the 
second IP version address contains the first IP version address (exemplified by page 39, line 23 - 
page 40, line 1; FIG. 6); and 

transmitting the TFT information to a Gateway GPRS (General Packet Radio Service) 
Support Node (GGSN) (exemplified by page 36, lines 9-24; FIG. 5). 

Independent claim 7 recites a method (exemplified by page 37, line 12 - page 39, line 10; 
page 40, line 8 - page 43, line 6; FIG. 17; FIGS. 18A-18B) for performing Traffic Flow 
Template (TFT) filtering according to Internet Protocol (IP) versions in a mobile communication 
system, the method comprising the steps of: 
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receiving a first TFT information from a mobile station which includes a second IP 
version address (exemplified by page 37, lines 13-18; FIG. 1 1), wherein the second IP version 
address contains a first IP version address (exemplified by page 37, lines 18-24; FIG. 1 1); 

generating a second TFT information using the first IP version address (exemplified by 
page 37, lines 18-26; FIG. 6), wherein the second TFT information contains an indication that 
the second IP version address contains the first IP version address (exemplified by page 37, lines 
18-26; FIG. 6); and 

filtering a received packet using the second TFT information (exemplified by page 38, 
line 1 - page 39, line 10, and FIGS. 16-17, FIGS. 18A-18B, and FIG. 20). 

Independent claim 17 recites an apparatus (exemplified by GSGN described on page 37, 
line 12 - page 39, line 10; page 40, line 8 - page 43, line 6, and illustrated in FIG. 16, FIG. 17, 
FIGS. 18A-18B, and FIG. 20) for performing Traffic Flow Template (TFT) filtering according to 
Internet Protocol (IP) versions in a mobile communication system, the apparatus comprising: 

receiving means (exemplified by page 37, lines 13-18 and FIG. 1 1) for receiving a first 
TFT information from a mobile station which includes a second IP version address, wherein the 
second IP version address contains a first IP version address; 

means (exemplified by page 37, lines 18-26 and FIG. 6) for generating a second TFT 
information using the first IP version address, wherein the second TFT information contains an 
indication that the second IP version address contains the first IP version address; and 

filtering means (exemplified by page 38, line 1 - page 39, line 10, and FIG. 16, FIG. 17, 
FIGS. 18A-18B, and FIG. 20) for filtering a received packet using the second TFT information. 

Independent claim 23 recites an apparatus (exemplified by UE described on page 39, line 
1 1 - page 40, line 7, page 43, line 9 - page 45, line 7, and illustrated in FIG. 5, FIGS. 19A-19B) 
for performing Traffic Flow Template (TFT) filtering according to Internet Protocol (IP) 
versions in a mobile communication system, the apparatus comprising: 

a controller (exemplified by page 39, line 1 1 - page 40, line 7, FIG. 1 1) for extracting a 
first IP version address from a second IP version address, wherein the second IP version address 
contains a first IP version address, and for generating TFT information from the first IP version 



-4- 



address, wherein the TFT information contains an indication that the second IP version address 
contains a first IP version address; and 

transmission means (exemplified by page 36, lines 9-24, FIG. 5) for transmitting the TFT 
information to a Gateway GPRS (General Packet Radio Service) Support Node (GGSN). 

VI. Grounds of Rejection to be Reviewed on Appeal 

The grounds of rejection for review on appeal are: 

(a) the rejection of claims 1, 7, 12-18 and 23-28 under 35 U.S.C. § 103(a) as being 
unpatentable over over U.S. Patent Publication No. 2003/0221016 to Jouppi et 
al. (hereinafter- Jouppi) in view of U.S. Patent No. 7,145,919 to Krishnarajah 
et al. (hereinafter- Krishnarajah). 

VII. Arguments 

A. Independent Claim 1 is Not Unpatentable Over Jouppi In View of 
Krishnarajah 

Claim 1 is rejected under 35 U.S.C. 103(a) as being unpatentable over Jouppi and 
Krishnarajah. According to the Final Office Action mailed June 16, 2008, among other things, 
Jouppi is cited for allegedly teaching (1) "extracting a first IP version address based information 
from a source second IP version address, wherein the second IP version address contains the first 
IP version", and (2) "generating TFT information using the first IP address wherein the TFT 
information contains an indication that the second IP version address contains the first IP version 
address". See page 3, line 14 - page 4, line 9 of the Final Office Action. On the other hand, 
Krishnarajah is cited for allegedly disclosing "identifying] a flow/packet and transmit it on the 
radio bearer configured with the corresponding treatment/class" (see page 5, line 12-13 of the 
Final Office Action), which, according to the Examiner, when combined with the teaching of 
Jouppi, will arrive at the subject matter recited in claim 1 . 

Applicant respectfully submits that Jouppi and Krishnarajah, taken either singly or in 
combination, does not teach or suggest the subject matter recited in claim 1, since, unlike the 
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subject matter recited in claim 1, neither Jouppi and Krishnarajah has any relevance to any 
scheme designed for reducing computation-load caused by bit-computations associated with 
second IP version addresses each containing a first IP version address during TFT filtering 
operations. Further, Applicant respectfully submits that, for the most part, the arguments 
advanced by the Examiner in both the Final Office Action and the Advisory Action are largely 
not directed to the very subject matter recited in claim 1, and therefore the Examiner's arguments 
are invalid. 

1. Jouppi and Krishnarajah, taken either singly or in combination, do 
not teach or suggest the subject matter recited in claim 1 

Claim 1 recites a combination, which comprises, inter alia, extracting a first IP version 
address from a source second IP version address, wherein the second IP version address 
contains the first IP version address; and generating TFT information using the first IP version 
address, wherein the TFT information contains an indication that the second IP version address 
contains the first IP version address. As disclosed in the specification, these two steps are 
designed to turn the otherwise more load-intensive bit computations associated with the second 
IP version address (e.g. IPv6 address) into the less load-intensive bit computations associated 
with the first IP version address (e.g. IPv4 address) when performing TFT filtering operations 
(see step 1963 of Fig. 19B), and therefore drastically reduce the overall load of bit computations 
involved during TFT filtering operations (see FIG. 23 and page 49, line 5-17). 

Jouppi, which although is also related to IPv6 addresses as well as generating a TFT 
filter, is directed to a scheme aimed to solve a security problem, rather than a computation load 
problem. In particular, Jouppi is irrelevant to the claimed steps of extracting a first IP version 
address from a source second IP version address and generating TFT information using the first 
IP version address. 

More specifically, Jouppi 's scheme is designed to overcome the prior art problem 
associated with the GGSN of a GPRS system being unable to effectively distinguish a legitimate 
packet directed to a mobile station from a malicious packet also directed to the same mobile station. 
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According to Jouppi, in the prior art, a mobile station is assigned with a 128-bit IPv6 address, with 
the 64-bit prefix uniquely allocated to the mobile station and the remaining 64 bits being reserved 
for a suffix. The suffix, which comprises an interface identifier, however, is only optional for the 
mobile station as far as identifying the mobile station is concerned. Consequently, an attack may 
launch against the mobile station by exploiting the optional nature of the interface identifier in the 
form of inundating malicious packets directed to IPv6 addresses having configurations interpreted 
as directed to the mobile station, the configurations invariably being that the 64-bit prefix is the 64- 
bit prefix uniquely assigned to the mobile station and the 64-bit suffix is a suffix comprising a 
random interface identifier. See paragraph [0004] of Jouppi. 

Because the prior art only uses the 64-bit prefix of a destination IPv6 address as the criterion 
to filter out packets not intended for the mobile station, the prior art cannot effectively filter out 
those malicious packets, which, as discussed above, have their respective destination IP addresses 
conforming to the above-described configurations. To solve this problem, Jouppi discloses a scheme 
in which an interface identifier is either first allocated to the mobile station (see paragraph [0006] of 
Jouppi), or first extracted from a source IPv6 address (see paragraph [0009] of Jouppi), and a TFT 
filter containing the interface identifier information is then included among other active TFT filters, 
so that legitimate packets directed to the mobile station can be distinguished from malicious packets 
also directed to the mobile station. 

Hence, Jouppi's scheme is irrelevant to the computation-load problem that the claimed 
combination is designed to solve. To be more specific, Jouppi, at best , teaches extracting an 
interface identifier (included in the 64-bit suffix), and generating a TFT information using the 
extracted interface identifier, for the purpose of distinguishing between legitimate packets and 
malicious packets. However, extracting a 64-bit interface identifier from an IPv6 address (as 
disclosed in Jouppi) cannot be construed as extracting a first IP version address from a source 
second IP version address (as recited in claim 1). Nor can generating a TFT information using the 
extracted interface identifier (as disclosed in Jouppi) be construed as generating TFT information 
using the first IP version address (as recited in claim 1). 
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Such findings are hardly surprising. The objective of Jouppi' s scheme is to distinguish 
between legitimate packets and malicious packets and thus solving a security problem. By contrast, 
the claimed combination is advantageous in that it can turn the otherwise more load-intensive bit 
computations associated with the second IP version address into the less load-intensive bit 
computations associated with the first IP version address and thus drastically reduce the overall 
load of bit computations associated with performing TFT filtering operation. 

Accordingly, Jouppi does not disclose, teach, or suggest the claimed combination including 
the steps of extracting a first IP version address from a source second IP version address, 
wherein the second IP version address contains the first IP version address; and generating TFT 
information using the first IP version address, wherein the TFT information contains an 
indication that the second IP version address contains the first IP version address. 

Turning to the cited secondary reference Krishnarajah, similar to Jouppi, the scheme 
disclosed in Krishnarajah is also irrelevant to the problem that the claimed combination 
advantageously resolves, that is, to reduce the bit-computation load associated with performing 
TFT filtering operation. Specifically, Krishnarajah's scheme is designed to provide different 
priority treatments to different portions of a pay load and therefore allow the scarce radio 
bandwidth to be used more efficiently by higher priority services. See col. 2, lines 21 - 36 of 
Krishnarajah. In Krishnarajah, with respect to IP versions, such as IPv6 and IPv4, they are 
merely mentioned in the context of an IP header of a packet as may be used to identify the 
priority treatment of the packet and map the packet to an IP data "flow". See col. 6, lines 44-49. 
For example, according to Krishnarajah, the flow label of an IPv6 header may be used to identify 
a flow corresponding to a particular priority treatment (see col. 6, lines 55-67 and col. 14, lines 
44-46), whereas the TOS filed in the IPv4 header may similarly be used to indicate a subflow 
corresponding to a particular priority treatment (see col. 14, lines 52 - 56). In addition, although 
TFT filtering is also mentioned in Krishnarajah, it is merely briefly disclosed as a mechanism of 
directing each flow (corresponding to a priority treatment) to the appropriate radio bearer. See 
col. 14, lines 38-52. 
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Hence, in Krishnarah, the two IP versions IPv6 and IPv4 are not disclosed in the context 
of extracting a first IP version address from a source second IP version address, wherein the 
second IP version address contains the first IP version address, as recited in claim 1 . Nor is its 
TFT filtering disclosed in the context of generating TFT information using the first IP version 
address, as recited in claim 1. In particular, the scheme disclosed in Krishnarajah is for providing 
different priority treatments to different portions of a payload and therefore allow the scarce 
radio bandwidth to be used more efficiently by higher priority services, an objective that is 
unrelated to the the claimed combination discussed above. 

Consequently, Jouppi and Krishnarajah, taken singly or in combination, do not disclose, 
teach, or suggest extracting a first IP version address from a source second IP version address, 
wherein the second IP version address contains the first IP version address; and generating TFT 
information using the first IP version address, wherein the TFT information contains an 
indication that the second IP version address contains the first IP version address, as recited in 
claim 1. Accordingly, Jouppi and Krishnarajah, taken singly or in combination, do not disclose, 
teach, or suggest the subject matter recited in claim 1 . 

2. The Examiner's grounds of rejection are invalid because the 
Examiner's arguments are largely not directed to the subject matter 
recited in claim 1 

Turning to the Examiner's grounds of rejection of claim 1, among other things, the 
Examiner alleges that Jouppi teaches "extracting a first IP version address based information 
from a source second IP version address, wherein the second IP version address contains the first 
IP version address", citing paragraph [0002], lines 9-12 and paragraph [0006], lines 9-22 of 
Jouppi. See page 3, line 14 - page 4, line 2 of the Final Office Action. 

However, nowhere does claim 1 recite "extracting a first IP version address based 
information from a source second IP version address". Rather, claim 1 recites "extracting a first 
IP version address from a source second IP version address". Hence, the subject matter that the 
Examiner addresses is not the subject matter recited in claim 1 . 
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On the other hand, paragraph [0002], lines 9-12 of Jouppi is only related to primary and 
secondary PDP context as used as in a UMTS system, while paragraph [0006], lines 9-22 of 
Jouppi is only related to preventing transmission of packets using random interface identifiers 
with a filter implemented using a predetermined interface identifier. Hence, neither of the two 
cited excerpts has any relevance to extracting a first IP version address from a source second IP 
version address, wherein the second IP version address contains the first IP version address, as 
recited in claim 1 . 

Similarly, since nowhere does Jouppi teach extracting a first IP version address from a 
source second IP version address, contrary to the Examiner's assertion, paragraph [0039], lines 
11-12 and paragraph [0006], lines 19-22 do not teach or suggest generating TFT information 
using the first IP version address, wherein the TFT information contains an indication that the 
second IP version address contains the first IP version address, as recited in claim 1 . 

Further, the Examiner alleges that Krishnarajah teaches "identifying] a flow/packet and 
transmit it on the radio bearer configured with the corresponding treatment/class" (see page 5, 
line 12-13 of the Final Office Action), which, according to the Examiner, when combined with 
the teaching of Jouppi, will arrive at the subject matter recited in claim 1. However, 
"identifying] a flow/packet and transmit it on the radio bearer configured with the 
corresponding treatment/class", as the Examiner alleges that Krishnarajah teaches, is irrelevant 
to the very subject matter recited in claim 1. Hence, once again, the Examiner fails to address the 
correct subject matter recited in claim 1. Accordingly, the Examiner's assertion that 
Krishnarajah, when combined with Jouppi, will arrive at the subject matter recited in claim 1 is 
also invalid. 

In the Advisory Action mailed October 7, 2008, the Examiner furnishes one page of 
comments, arguing that the combination of Jouppi and Krishnarajah will arrive at the subject 
matter recited in claim 1. With respect to Jouppi, the Examiner's comments do not pinpoint to 
any particular part of disclosure that teaches the subject matter recited in claim 1 . It appears that 
the most relevant portion of the Examiner's comments relating to Jouppi is the Examiner's 
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assertion, which, in verbatim, states "Examiner understanding of filtering and extracting is to be 
same as the functional objective is achieved by both in identifying parameters for IPv6 addresses 
of packets as an end result" This assertion, once again, does not address the very subject matter 
recited in claim 1, since even assuming for the sake of argument that filtering and extracting 
could be regarded as the same in the context of extracting information from an IP version 
address, the Examiner's assertion still does not address the very subject matter recited in claim 1. 
In addition, with respect to Krishnarajah, the Examiner's comments are largely recounting of 
disclosure made in Krishnarajah. However, what is notably missing is any attempt made by the 
Examiner to articulate how Krishnarajah may possibly cure the deficiencies of Jouppi. Hence, 
once again, the Examiner fails to address the very subject matter recited in claim 1. 

Accordingly, Applicant respectfully submit that because the Examiner's arguments are 
largely made without addressing the very subject matter recited in claim 1, the Examiner fails to 
discharge the Examiner's statutory burden of establishing a prima facie case of obviousness. At 
least for this reason, the rejection of claim 1 should be withdrawn. 

3. Summary 

In summary, Jouppi and Krishnarajah, taken singly or in combination, do not disclose, 
teach, or suggest extracting a first IP version address from a source second IP version address, 
wherein the second IP version address contains the first IP version address; and generating TFT 
information using the first IP version address, wherein the TFT information contains an 
indication that the second IP version address contains the first IP version address, as recited in 
claim 1. Accordingly, Jouppi and Krishnarajah, taken singly or in combination, do not disclose, 
teach, or suggest the subject matter recited in claim 1. The rejection of claim 1 should therefore 
be withdrawn. Further, as pointed-out above, Examiner's arguments are largely made without 
addressing the very subject matter recited in claim 1. Accordingly, the Examiner fails to 
discharge the Examiner's statutory burden of establishing a prima facie case of obviousness. At 
least for this reason, the rejection of claim 1 should be withdrawn. 
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B. Claims 7, 12-18 and 23-28 are Not Unpatentable Over Jouppi In View 
of Krishnarajah 

Claim 23 contains similar recitation to claim 1 with respect to extracting a first IP 
version address from a source second IP version address, wherein the second IP version address 
contains the first IP version address', and generating TFT information using the first IP version 
address, wherein the TFT information contains an indication that the second IP version address 
contains the first IP version address, as recited in claim 1 . Accordingly, for at least the same 
reasons stated above in connection with claim 1, claim 23 should also be allowable over Jouppi 
in view of Krishnarajah. 

Claim 7 recites, inter alia, receiving a first TFT information from a mobile station which 
includes a second IP version address, wherein the second IP version address contains a first IP 
version address, and generating a second TFT information using the first IP version address, 
wherein the second TFT information contains an indication that the second IP version address 
contains the first IP version address. As discussed above in connection with claim 1, neither 
Jouppi nor Krishnarajah has any relevance to generating TFT information using the first IP 
version address (which is contained in the second IP version address) wherein the second TFT 
information contains an indication that the second IP version address contains the first IP version 
address. Accordingly, Jouppi and Krishnarajah, taken singly or in combination, do not disclose, 
teach, or suggest the combination claimed in claim 7. Claim 7 should therefore be allowable 
over Jouppi in view of Krishnarajah. 

Claim 17 contains similar recitations to claim 7 with respect to receiving a first TFT 
information from a mobile station which includes a second IP version address, wherein the 
second IP version address contains a first IP version address, and generating a second TFT 
information using the first IP version address, wherein the second TFT information contains an 
indication that the second IP version address contains the first IP version address, as recited in 
claim 7. Accordingly, for at least the same reasons stated above in connection with claim 7, 
claim 17 should also be allowable over Jouppi in view of Krishnarajah. 
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Claims 12-16, 18 and 24-28 should be allowable over Jouppi in view of Krishnarajah at 
least by virtue of their dependency from one or more of allowable claims 1, 7, 17 and 23 
respectively. 



Accordingly, claims 7, 12-18 and 23-28 are not unpatentable over Jouppi in view of 
Krishnarajah. The rejection of claims 7, 12-18 and 23-28 should therefore be withdrawn. 

C. Conclusion 

For the reasons presented herein, Applicants submit that claims 1, 7, 12-18 and 23-28 are 
not unpatenable in view of the cited references of record. Accordingly, reversal of the final 
rejection is requested, and allowance of claims 1, 7, 12-18 and 23-28 is respectfully requested. 



Roylance, Abrams, Berdo & Goodman, L.L.P. 
1300 19 th Street, N.W., Suite 600 
Washington, D.C. 20036 
(202) 659-9076 

Dated: January 12, 2009 



Respectfully submitted, 




Jundong Ma 
Reg. No. 61,789 
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VIII. CLAIMS APPENDIX 

1. A method for performing Traffic Flow Template (TFT) filtering according to Internet 
Protocol (IP) versions in a mobile communication system, the method comprising the steps of: 

extracting a first IP version address from a source second IP version address, wherein the 
second IP version address contains the first IP version address; and 

generating TFT information using the first IP version address, wherein the TFT 
information contains an indication that the second IP version address contains the first IP version 
address; and 

transmitting the TFT information to a Gateway GPRS (General Packet Radio Service) 
Support Node (GGSN). 

7. A method for performing Traffic Flow Template (TFT) filtering according to Internet 
Protocol (IP) versions in a mobile communication system, the method comprising the steps of: 

receiving a first TFT information from a mobile station which includes a second IP 
version address, wherein the second IP version address contains a first IP version address; 

generating a second TFT information using the first IP version address, wherein the 
second TFT information contains an indication that the second IP version address contains the 
first IP version address; and 

filtering a received packet using the second TFT information. 

12. The method as set forth in claim 1, further comprising 

allowing User Equipment (UE) to perform the steps of extracting, generating TFT 
information and transmitting the generated TFT information to a Gateway GPRS (General 
Packet Radio Service) Support Node (GGSN); 

allowing the GGSN to store the TFT information received from the UE and to extract the 
first bits representing the first IP version address from the second IP version address when the 
second IP version address has the first IP version address inserted; and 

allowing the GGSN to perform the TFT packet filtering using the extracted first IP 
version address. 
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13. The method as set forth in claim 1, 7 or 12, wherein the second IP version address 
into which the first IP version address is inserted is a first IP version-compatible second IP 
version address or a first IP version-mapped second IP version address. 

14. The method as set forth in claim 13, wherein the first IP version-compatible second 
IP version address is an address used between networks capable of supporting both a first IP of 
the first IP version and a second IP of the second IP version. 

15. The method as set forth in claim 13, wherein the first IP version-mapped second IP 
version address is an address used between a network capable of supporting only a first IP of the 
first IP version and a network capable of supporting both the first IP of the first IP version and a 
second IP of the second IP version. 

16. The method as set forth in claim 1, 7 or 12, wherein the first IP version is an IPv4 (IP 
version 4) and the second IP version is an IP version 6 (IPv6). 

17. An apparatus for performing Traffic Flow Template (TFT) filtering according to 
Internet Protocol (IP) versions in a mobile communication system, the apparatus comprising: 

receiving means for receiving a first TFT information from a mobile station which 
includes a second IP version address, wherein the second IP version address contains a first IP 
version address; 

means for generating a second TFT information using the first IP version address, 
wherein the second TFT information contains an indication that the second IP version address 
contains the first IP version address; and 

filtering means for filtering a received packet using the second TFT information. 

18. The apparatus as set forth in claim 17, wherein said filtering means comprises: 

a TFT packet filtering procedure for extracting the first IP version address from the second IP 
version address when an IP address of received packet data corresponds to the second IP version 
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and the IP address is the second IP version address into which the first IP version address is 
inserted, and for performing the TFT packet filtering using the second TFT information. 

23. An apparatus for performing Traffic Flow Template (TFT) filtering according to 
Internet Protocol (IP) versions in a mobile communication system, the apparatus comprising: 

a controller for extracting a first IP version address from a second IP version address, 
wherein the second IP version address contains a first IP version address, and for generating TFT 
information from the first IP version address, wherein the TFT information contains an 
indication that the second IP version address contains a first IP version address; and 

transmission means for transmitting the TFT information to a Gateway GPRS (General 
Packet Radio Service) Support Node (GGSN). 

24. The apparatus as set forth in claim 23, further comprising the Gateway GPRS 
(General Packet Radio Service) Support Node (GGSN) which comprises: 

a TFT packet filtering procedure for extracting the first IP version address from the 
second IP version address when the IP address of the received packet data corresponds to the 
second IP version and the IP address is the second IP version address into which the first IP 
version address is inserted, and for performing the TFT packet filtering using the first IP version 
address; and 

a memory for storing the TFT information received from the UE. 

25. The apparatus as set forth in claim 17 or 23, wherein the second IP version address 
into which the first IP version address is inserted is a first IP version-compatible second IP 
version address or a first IP version-mapped second IP version address. 

26. The apparatus as set forth in claim 25, wherein the first IP version-compatible second 
IP version address is an address used between networks capable of supporting both a first IP of 
the first IP version and a second IP of the second IP version. 
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27. The apparatus as set forth in claim 25, wherein the first IP version-mapped second IP 
version address is an address used between a network capable of supporting only a first IP of the 
first IP version and a network capable of supporting both the first IP of the first IP version and a 
second IP of the second IP version. 

28. The apparatus as set forth in claim 17 or 23, wherein the first IP version is an IP 
version 4 (IPv4) and the second IP version is an IP version 6 (IPv6). 
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EVIDENCE APPENDIX 

No evidence under 37 C.F.R. § 1 . 1 30, 1.131 or 1 . 1 32 is relied upon in this Appeal. 
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RELATED PROCEEDINGS APPENDIX 

None 
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